This is a deadlock bug.
The following is an example of deadlock thread dump:
"SSLEngine Task Dispatcher": waiting to lock monitor 0x0000000005eec650 (object 0x0000000040726148,
a java.lang.Object), which is held by "main"
"main": waiting to lock monitor 0x0000000005eec8f0 (object 0x0000000040726088,
a com.sun.net.ssl.internal.ssl.SSLEngineImpl), which is held by "SSLEngine Task Dispatcher"
Java stack information for the threads listed above:
===================================================
"SSLEngine Task Dispatcher":
at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:610)
- waiting to lock <0x0000000040726148> (a java.lang.Object)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:808)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:734)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:197)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:511)
at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Handshaker.java:453)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Handshaker.java:867)
- locked <0x0000000040726088> (a com.sun.net.ssl.internal.ssl.SSLEngineImpl)
at Test6492872.doTask(Test6492872.java:209)
at Test6492872.access$0(Test6492872.java:204)
at Test6492872$1.run(Test6492872.java:247)
"main":
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:462)
- waiting to lock <0x0000000040726088> (a com.sun.net.ssl.internal.ssl.SSLEngineImpl)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1062)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1034)
- locked <0x0000000040726148> (a java.lang.Object)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:452)
at Test6492872.runTest(Test6492872.java:267)
at Test6492872.main(Test6492872.java:168)
More details about this bug are at
JDK-6492872 JIRA page.
This bug is reproduced under JDK 1.6.0.
It affects since JDK 1.6.0, and has been fixed since JDK 1.6.0_02.
Execute the following scripts to run the test to reproduce the bug (assume the location of the jdk6 test project is jdk_test_home).
Linux:
${jdk_test_home}/scripts/6492872.sh [--monitoroff] [--javaloc path]
Windows:
%jdk_test_home%\scripts\6492872.bat [--monitoroff] [--javaloc path]
Example:
Use monitor to report and terminate the program when deadlock happens:
${jdk_test_home}/scripts/6492872.sh
Turn off monitor:
${jdk_test_home}/scripts/6492872.sh
--monitoroff
| Option | Function |
| --monitoroff, -mo | Turn off to stop reporting bug messages and ending program
when test runs into the expected concurrency bug which is a deadlock. User has to terminate the program manually when this option is set. |
| --javaloc | The location of JDK that is eligible to reproduce the bug, if your java environment is not eligible.
In this case, it's JDK 1.6.0. It should be the absolute path to the JDK's java starter and ended with "/". For example: ~/jdk/home/jdk1.6.0/bin/ |